It is known that network overhead can impact the end-to-end performance of client-server applications. The impact of network overhead may be increased when the number of networks, the number of network elements and/or the geographical distance between clients and servers increases. For example, network delay caused by the distance between a client and a server can significantly reduce the client's quality of experience when a single user request requires multiple calls to databases, application servers and/or the client.
Network-related performance degradation in client-server communication can be reduced by explicitly managing network traffic. Hereto network operators can e.g. assign paths to specific end-points (e.g. using MPLS, VPNs or Fiber-optic circuits) or allow applications to express a quality of service requirement (e.g. using DiffServ or IntServ), which can be used to prioritize application traffic. More recently, Software Defined Networks enable network operators more fine-grained control over data flows using a centralized control plane, e.g. by rerouting data flows to avoid bottlenecks.
Though known network management solutions can avoid bottlenecks or prioritize traffic, they cannot change the end-points, i.e. the location of the client and server. As a result, potential dimensioning problems in the network cannot be solved and a reduction of network resources (e.g. minimizing the number of hops, optimizing bandwidth or explicit control of network resources) cannot be achieved. The effect of this is that if many demanding client-server applications request the use of a low-capacity network element, there is no network management solution to improve the perceived quality of the network other than denying or rate limiting the service.
Network service providers are known that specialize in the control, operation, and maintenance of networks that enable use of cloud services. Such network service providers typically do not provide cloud service providers the capability to control how their cloud services are accessed. Furthermore, cloud service providers typically do not allow the network service provider to optimize cloud service delivery that takes network service delivery into account. This leads to the situation that both the network service provider and cloud service provider are unable to arrange the network and other fundamental computing resources in a way that provides optimal services to the end-user with optimal resource usage.
Recent developments in the 3GPP standard for mobile communication relate to Long Term Evolution (LTE) networks and devices. LTE, also known as 4G (i.e. fourth generation) mobile communications standard, is a standard for wireless communication of high-speed data for mobile phones and data terminals. It is a successor of GSM/EDGE (also known as 2G or 2.5G) and UMTS/HSPA (also known as 3G) network technologies, increasing the capacity and speed using a different radio interface together with core network improvements.
The above identified problem of not being able to provide optimal services to the end-user with optimal resource usage can also be applied to LTE networks. The design of LTE networks does not include management and coordination of computing or storage resources in combination with network resources.
Client devices typically attach to an Internet gateway by requesting a connection to an Access Point Name (APN), which leads to a tunnel to a Public Data Network (PDN) gateway that provides the actual IP services such as addressing and Internet gateway functionality. Alternatively, a (home) router or H(e)NodeB (i.e. LTE base station) in the network service provider's network can function as Internet gateway. Depending on the location in the network service provider's network, traffic over the Internet gateway is routed over the backhaul (i.e. the network connecting the base station or (home) router to the core network) to its core network before being routed to the Internet.
In known 3GPP proposals the H(e)NodeB's can be configured to redirect data traffic to local devices through a local area network or to redirect traffic through the network of another Internet service provider. An example of such proposal can be found in 3GPP specification TR 23.829 Release 10 entitled “Local IP Access and Selected IP Traffic Offload (LIPA/SIPTO)”. The goal of LIPA/SIPTO is to avoid congestion in the backhaul or core network by redirecting traffic over an available fixed broadband network, and to support IP communication with local devices, such as a home printer or media center. A client device is connected to the access network through an H(e)NodeB, (Home) router or PDN-gateway as the Internet gateway, which supports packet filtering and redirection of traffic through network address translation.
With cloud computing a client device uses a cloud service at a cloud service provider. A cloud service is a service that is delivered and consumed on demand at any time, through any access network, using any connected devices using cloud computing technologies. A cloud service user (CSU) is a person or organization that consumes delivered cloud services, typically using a client device. A CSU can include intermediate users that will deliver cloud services provided by a cloud service provider (CSP) to actual users of the cloud service, i.e. end users. End users can be persons, machines, or applications. Cloud computing is a model for enabling service users to have on-demand network access to a shared pool of configurable computing resources (e.g. networks, servers, storage, applications and services), that can typically be provisioned and released with minimal management effort or service-provider interaction. Cloud computing enables the cloud services. It is considered from a telecommunication perspective that users are not buying physical resources but cloud services that are enabled by cloud computing environments. Cloud infrastructure as a service (IaaS) is a category of cloud services where the capability provided by the cloud service provider to the cloud service user is to provision virtual processing, storage, intra-cloud network connectivity services (e.g. VLAN, firewall, load balancer and application acceleration), and other fundamental computing resources of the cloud infrastructure where the cloud service user is able to deploy and run arbitrary application. Inter-cloud computing allows on-demand assignment of cloud resources, including computing, storage and network, and the transfer of workload through interworking of cloud systems. From the viewpoint of a CSP, inter-cloud computing can be implemented in different manners, including inter-cloud peering, inter-cloud service broker and inter-cloud federation. These manners correspond to distinct possible roles that a CSP can play when interacting with other CSPs. Inter-cloud peering provides direct inter-connection between two CSPs. An inter-cloud service broker (ISB) provides indirect interconnection between two (or more) CSPs achieved through an interconnecting CSP which, in addition to providing interworking service functions between the interconnected CSPs, also provides brokering service functions for one (or more) of the interconnected CSPs. ISB also covers the case in which one (or more) of the interconnected entities receiving the brokering service is a cloud service user (CSU). Brokering service functions generally includes but is not limited to, the following three categories: service intermediation, service aggregation and service arbitrage. Inter-cloud federation is a manner to implement inter-cloud computing in which mutually trusted clouds logically join together by integrating their resources. Inter-cloud federation allows a CSP to dynamically outsource resources to other CSPs in response to demand variations.
A mobile cloud is a model in which mobile applications (i.e. application for mobile devices) are built, powered and hosted using cloud computing technology. The client device may acts as the on-device gateway, which enables the user to access the information stored and processed within the cloud. Mobile cloud applications can send processing or storage tasks to servers located in a cloud, receive, and display the results and uses cloud resources to store data or to execute functions normally performed by the client device (e.g. pre-process web pages for optimal display on a mobile device, transcoding, storing application data). Mobile cloud applications can be downloaded on the client device or directly accessed via the web browser (e.g. using HTML5 and Javascript) and make use of client device capabilities and sensors, such as camera's, GPS, or microphone to deliver a service.
The mobile cloud application provider typically cannot control the network between the cloud server and the client device, though communication between client devices and cloud servers requires broadband connectivity. Moreover, streaming media or gaming applications may require network connectivity within certain latency and jitter bounds. With the increasing need for faster networks to support new and more demanding applications, network service providers typically increase network capacity to meet demands. Other options, such as prioritizing traffic require advanced network management and only improve the quality of service within the network service provider's boundaries. But congestion, delay, errors, and failures outside the network service provider's boundaries may still negatively impact application performance.
Intercloud computing enables end-users to create and transfer servers over a multitude of Cloud Service Providers (CSP). This ability allows end-users to implement three functions: load balancing, cloud bursting and fail-over. In a load balancing setup, servers are copied over multiple cloud server providers. A proxy server distributes client requests over the servers. Cloud bursting enables a server to distribute workload over multiple cloud service providers if local resources are insufficient to handle the workload. Load balancing can be used to distribute client requests, but the servers may also handle part of the workload to process client requests. End-users can also implement fail-over mechanisms when servers can be distributed over multiple resource providers.
An Intercloud service broker adds the capability to intermediate, aggregate and arbitrate between cloud service providers. Depending on application requirements (e.g. location, pricing, resources) the Intercloud service broker provides functionality to match cloud resource buyers (e.g. end-users, cloud service provider or reseller) to cloud resource sellers (e.g. cloud service provider or reseller). The goal is to provide the best possible match between offered and required resources to run a server and to abstract individual cloud service providers into a single entry-point for cloud services. An Intercloud service broker is required to provide end-users the capability for implementing load balancing, cloud bursting, and fail-over in the Intercloud.
Cloud service brokers can be used to match server requirements (e.g. price, CPU, memory, location) to cloud locations. Cloud service brokers have no notion of the network between clients and servers and do not model network context specific details of client devices either. Therefore, cloud service brokers do not significantly reduce the overhead of induced by traversing the network service provider's network(s), which negatively impacts client-server communication (e.g. network latency, propagation delay, buffering/queuing in network devices, errors, failures).
The current 3GPP proposals on LIPA/SIPTO provide no solution to optimize client-server communication, because it provides no mechanism to minimize or avoid the overhead of the network. Consequently, allocating servers on cloud locations in the Internet using e.g. an Inter-cloud service broker does not lead to significant benefits to clients or a reduction of traffic at the network service provider.
There is need for a solution in which server functions can be placed in such a way that desirable operational parameters of the network can be achieved with relation to client devices.